The present disclosure relates to call identification by a Session Initiation Protocol (“SIP”) Back To Back User Agent (“B2BUA”).
Session Initiation Protocol (“SIP”) is a protocol or standard for handling an interactive user session. The session may involve any multimedia element. Voice over IP (“VoIP”) calls may use SIP. SIP is used as a signaling protocol in many different VoIP offerings, including for example Microsoft Live Communications Server and the 3GPP IP Multimedia Subsystem (“IMS”) architecture. Generally, SIP is a protocol for establishing and using multimedia communications.
A Back To Back User Agent (“B2BUA”) may be a logical entity that acts as an intermediary in a SIP call. A Signaling gateway that is part of a Session Border Control (“SBC”) may be an example of a B2BUA. A B2BUA may also be an interface in an IP Multimedia Subsystem (“IMS”) network between the IMS and an external network. The B2BUA may be a proxy for both ends of a SIP call and act as a server on one end and a client on the other end that handles all SIP signaling. In one example, the B2BUA may act as both a client (UAC) and a server (UAS) to both ends of a call. When one client sends a request, acting as a UAC, to the B2BUA, which acts as a UAS to receive the request. The B2BUA may then act as a UAC to send the potentially modified request to another endpoint, which uses UAS functionality to receive the request. If the endpoint then responds, the response is sent using UAC from the endpoint to UAS on the B2BUA. After B2BUA processing, the response is transmitted from the B2BUA via UAC functionality before being received back at the starting endpoint via UAS functionality. In other words, a request may be both sent via UAC functionality and received via UAS functionality.
Specifically, in the SIP specification for the RFC 3261 standard, B2BUA is defined as:                . . . a logical entity that receives a request and processes it as a user agent server (‘UAS’). In order to determine how the request should be answered, it acts as a user agent client (‘UAC’) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.        
The B2BUA may allow for additional tracking of calls as well as allow for new features that would otherwise be unavailable in a traditional end to end call. The B2BUA may receive, respond to, and generate requests. In other words, the SIP signaling, from call origination to call termination can be controlled by the B2BUA. The B2BUA may include call management functions, network interworking, SIP-based VoIP interworking, managing/monitoring entire call state, cloaking endpoint location, centralized call management, and the hiding of network internals. It may maintain records of all requests or connections that are established by tracking each call. Consequently, value-added features may be offered in the call as a result of the B2BUA.
The RFC 3261 specification does not contain any recommendations for B2BUAs on how to associate incoming/outgoing/multiple call legs belonging to the same call/conference. Current B2BUA implementations normally generate a random and unique Call-ID header for the outbound call leg. RFC3261 describes a Call-ID as a header field acting as a unique identifier to group together a series of messages. It may be the same for all requests and responses sent by either UA in a dialog. In addition, the Call-ID may be one of three elements, in addition to the ‘To’ tag and the ‘From’ tag, that define a SIP dialog. The SIP dialog may define a unique peer-to-peer SIP relationship between two entities.
For example, for a message from user A to user B with Call-ID 1111 and another message also from user A to user B but with a Call-ID of 2222, there are two different dialogs or communications sessions. For instance, Call-ID 1111 could be for a VoIP session and Call-ID 2222 could be for an Instant Messaging session. The use of a B2BUA between the endpoints may disrupt the normal peer-to-peer communications between SIP endpoints. The technique used by a SIP endpoint to determine which SIP sessions are a part of a given conference is to rely on the Call-ID. All sessions with the same Call-ID at a given endpoint may be considered to be part of a single conference. If the B2BUA generates random Call-IDs on call legs that it extends, the endpoint will not be able to successfully recognize the conference because of the differing Call-IDs. The ability to maintain the same Call-ID may be required by endpoints for some SIP features, such as MICROSOFT'S MULTI-PARTY IM®. This is one scenario in which a constant Call-ID is required, however, there may be additional programs or circumstances that also require a constant Call-ID. In addition, there may be situations where call legs are terminated and later re-established. In this situation, the generation of a new Call-ID by the B2BUA makes it difficult for the endpoint to recognize that the “new” call leg is simply the reestablishment of the previous call leg. This may be important for historical call tracking.
FIG. 1 illustrates a related art conference setup. FIG. 1 shows a conference 100 in which three users 102, 104, 106 are connected according to the related art. The conference may be an instant messaging (“IM”) conference, Voice over IP (“VoIP”) call, or any other connection. In this example, there is no B2BUA in the network, so the calls are routed directly. Additionally, there may be a SIP proxy, but it is omitted from FIG. 1. Each User 102, 104, 106 is labeled independently. User A is 102, User B is 104, and User C is 106.
As shown in FIG. 1, User A originates a call with User B by sending an invitation 108 to join in a call. The call may be an IM session. As part of the invitation 108, User A creates a SIP Call-ID, such as 1234. The SIP Call-ID identifies the call. Subsequent to the invitation 108, User B requests 110 that User A invite User C into the call. User A sends invitation 112 to User C using the same Call-ID as from the invitation 108. The invitation 112 may also pass a list of conference participants notifying User C that User A and User B are in the call. User C may then send out invitations to the other parties in the conference. For example, User C sends out invitation 114 to User B using the same Call-ID to identify the call. Accordingly, conference 100 has three endpoints and each have the same Call-ID. From the perspective of an individual endpoint, all sessions that have the same Call-ID are considered to be part of the same conference.
FIG. 1 illustrates a system 100 that has a conference call between endpoints without the presence of a B2BUA. FIG. 2 illustrates a related art system using a B2BUA. Specifically, conference 200 illustrates a conference call is established with a B2BUA 208 in the network in which three users 202, 204, 206 are connected. Additionally, there may be a SIP proxy, but it is omitted from FIG. 2. Each User 202, 204, 206 is labeled independently. User A is 202, User B is 204, and User C is 206.
As shown in FIG. 2, User A originates a call by sending an invitation 210 to User B. User A creates a SIP Call-ID, such as 1234. The invitation 210 goes through the B2BUA 208. The B2BUA generates a new call leg 212 to User B. The generation of new call leg 212 results in the generation of a new Call-ID, such as 2000. User B subsequently may ask User A to also include User C in the call in 214. User A then sends an invitation 216 to User C using the same Call-ID used in the original invitation 210, which is Call-ID 1234, and passes a list of conference participants to User C. The invitation 216 goes through the B2BUA. The B2BUA generates a new call leg 218 to User C. The call leg 218 is generated with a new Call-ID, such as 3000. User C sends out invitation 220 to User B, who is the other user in the conference. The invitation 220 is sent using the same Call-ID that User C received, which is 3000. The invitation 220 goes through the B2BUA. The B2BUA may then generate a new call leg 222 to User C. Call leg 222 results in the generation of another new Call-ID, such as 4000.
The conference 200 that is attempted after call leg 222 includes multiple Call-IDs for the different call legs. At this point, User B is unable to correlate the sessions. User B's session with User A has an ID of 2000 and User B's session with User C has an ID of 4000. As a result, the conference may fail. Accordingly, the use of a B2BUA in the conference 100 results in a conference 200, which fails because of the inability of some endpoints to correlate the sessions between end users.